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Aeronautics and Space Administration. 
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California Institute of Technology. 
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ABSTRACT 


The Spacecraft Health Automated Reasoning Prototype (SHARP) is a system 
designed to demonstrate automated health and status analysis for multi-mission 
spacecraft and ground data systems operations. Telecommunications link analysis 
of the Voyager 2 spacecraft is the initial focus for the SHARP system demonstration 
which will occur during Voyager's encounter with the planet Neptune in August, 
1989, in parallel with real-time Voyager operations. 

The SHARP system combines conventional computer science methodologies 
with artificial intelligence (AI) techniques to produce an effective method for 
detecting and analyzing potential spacecraft and ground systems problems. The 
system performs real-time analysis of spacecraft and other related telemetry, and is 
also capable of examining data in historical context. 

This publication gives a brief introduction to the spacecraft and ground 
systems monitoring process at the Jet Propulsion Laboratory (JPL). It describes the 
current method of operation for monitoring the Voyager Telecommunications 
subsystem, and highlights the difficulties associated with the existing technology. 
The publication details the approach taken in the SHARP system to overcome the 
current limitations, and describes both the conventional and AI solutions 
developed in SHARP. 






* : WWt? *J5T'Xl$#fl3F ’9*^Pl!?ff ( *^flfi 3 kS(W V ' ~-‘ **? “Wife s* - 


r : '*rfvaw*w» '. 


ACKNOWLEDGEMENTS 

The authors wish to acknowledge the following people for their participation 
in the SHARP project: David J. Atkinson, task management; Harry J. Porta and 
Gains Martin, software development; Boyd Madsen, expert knowledge for Voyager 
and Galileo spacecraft telecommunications; and Bruce Elgin and Erann Gat, 
software contributions. 


iv 


CONTENTS 


INTRODUCTION 1 

CURRENT METHOD 2 

Required Data 2 

Limitations 3 

Diagnosis 4 

THE SHARP SOLUTION 4 

Conventional Automation 6 

Enhanced Graphical Capabilities 6 

Artificial Intelligence 14 

CONCLUSIONS 17 

REFERENCES 19 

APPENDIX 21 

Fi gures 

1. SHARP Telecom System Overview 5 

2. SHARP Top-Level System Status View 8 

3. Plotting Capabilities Available in SHARP 9 

4. SHARP Telecommunications Link Status Display 11 

5. SHARP Schematic Block Diagram of Voyager 

Telecommunications Subsystem 12 

6. SHARP Schematic Block Diagram of Spacecraft Receiver 

With Message From Diagnostician 13 

7. SHARP Artificial Intelligence Module 15 


v 


INTRODUCTION 


The Voyager 1 and Voyager 2 spacecraft were launched from Cape Canaveral, 
Florida, on August 20, 1977. The technology to track and monitor such probes was 
designed and developed in the early 1970's. This now-antiquated technology, 
coupled with the efforts of bright, resourceful scientists, has carried Voyager 2 
through near-fatal catastrophic events to three of our solar system’s outer planets (to 
four by August, 1989). Despite the spacecraft's failed radio receiver, sunlight damage 
to the photopolarimeter scientific instrument, and partially paralyzed scan platform 
(which houses Voyager's imaging system), these scientists have kept Voyager oper- 
ational, enabling the capture and transmission of vast amounts of invaluable infor- 
mation and images of the Jovian, Saturnian, and Uranian systems. 

During critical periods of the mission, up to 40 real-time operators are 
required to monitor the spacecraft’s 10 subsystems on a 24-hour, 7-day-per-week 
schedule. This does not include the numerous subsystem and scientific instrument 
specialists who must constantly be available on call to handle emergencies. 

As more and more solar system explorations are undertaken, it will become 
increasingly difficult to staff a large enough effort to support these expensive mis- 
sions. Currently there is one Mission Control Team and one Spacecraft Team for 
each flight project. JPL has initiated an effort to coordinate all missions through a 
central Space Flight Operations Center (SFOC) whose goal is to transition from 
single-project dedicated flight teams to one multi-mission teem that flies all space- 
craft. Within SFOC, the Voyager spacecraft will continue to be monitored through- 
out their extended mission of discovering the solar system heliopause (the bound- 
ary between the Sun's magnetic influence and interstellar space); the Magellan 
spacecraft, launched in May, 1989, is being tracked throughout its flight to Venus; 
the Galileo mission to Jupiter will be monitored; and other new flight projects will 
be observed throughout their operation by this single multi-mission flight team. 

The Spacecraft Health Automated Reasoning Prototype (SHARP) is an effort 
to apply artificial intelligence (Al) techniques to the task of multi-mission monitor- 
ing of spacecraft and diagnosis of anomalies. Ultimately, SHARP will ease the bur- 
den that multiple missions would inevitably place upon subsystem, scientific 
instrument, and Deep Space Network (antenna) experts. SHARP will automate 
many of the mundane analysis tasks, and reduce the number of operators required 
to perform real-time monitoring activities. The system will enhance the reliability 
of monitoring operations, and may prevent those types of errors that cause space- 
craft, such as the Soviet Phobos, to be lost. 

The Voyager 2 spacecraft was targeted for the SHARP effort since, at the time 
of selection, it was the only spacecraft in flight that had yet to complete its primary 
mission. The prototype effort was further focused to one subsystem so that specific 
concepts could be developed and then demonstrated in a vigorous operational set- 
ting: the spacecraft's encounter of the planet Neptune in August, 1989. The Tele- 
communications (Telecom) subsystem was chosen for the initial demonstration 
since anomalies occur on a frequent basis in this area, and the Telecom expert, Boyd 
Madsen, demonstrated enthusiastic support. The Telecommunications area also 



( presents the challenge of coordinating monitoring and diagnosis efforts of both the 
spacecraft and ground data systems (GDS). 

As with many other AI applications, in order to supply the AI component of a 
system with real data, a substantial effort was invested in the development of other 
aspects of the system. This entailed utilizing standard conventional computer sci- 
ence methodologies and enhanced graphical capabilities. The SHARP system effi- 
ciently incorporates these technologies to complement the use of AI techniques. 


CURRENT METHOD 

In current mission operations practice, each spacecraft is monitored daily, and 
during planetary encounters, monitoring is continuous. Three complexes of anten- 
nas located around the world comprise NASA's Deep Space Network (DSN): in the 
Mojave desert at Goldstone, California; near Canberra, Australia; and near Madrid, 
Spain. With the exception of occupations and a short gap between the Canberra and 
Madrid stations, the spacecraft is always in view from one of these Deep Space Sta- 
tions (DSS). Such a scheduled period of observance of the spacecraft by a DSS is 
called a pass. 


Required Data 

In order to effectively analyze the telecommunications link from the space- 
craft through the DSN and ultimately to the computers at JPL, a wide variety of 
information must be accessed and processed. This analysis occurs in real-time as 
well as prior to the scheduled spacecraft pass. 

Predicts are numerical predictions of acceptable threshold values for particu- 
lar spacecraft and DSS parameters. The current method of generating pass predicts is 
to search large hardcopy listings of raw predicts to find the correct spacecraft, station, 
time, and other approximated information. Predicts are then manually corrected, 
using a hand calculator, to reflect the actual spacecraft state and the results are man- 
ually recorded on a data sheet. 

Another piece of information pertinent to spacecraft monitoring is the Inte- 
grated Sequence of Events (ISOE). The ISOE is a hardcopy of scheduled spacecraft 
activity integrated with DSS information. ISOE data is used extensively throughout 
the monitoring process in predict data, alarm determination, graphics, and diagno- 
sis- The Voyager ISOE must be visually scanned, and Telecom events manually 
highlighted by the real-time operator so that the Telecom activity can be monitored. 
A handwritten correction sheet is issued for each modification to an ISOE. 
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Telemetry data from the spacecraft, tracking stations, and other relevant svs- 
tems is coUected m the JPL computers and separated into channels that are dis- 7 

J f °r r P rocessin 8 and anal ysis. These channels contain the values of 
undreds of spacecraft engineering parameters and station performance parameters. 

> an j 6 . s are P^ ott ^d on black-and-white computer screens and are visually 
monitored to ensure that they remain within their prespecified limits. 7 

., u ^i S ° C , riticaI t0 the communications link analysis are alarm limits, the 
reshold values for spacecraft and DSS performance. These values are selected 
according to the status of several parameters. However, the process to change these 
hmits is manual and must be performed in real-time. The procedure is so impedi- 
ng and occurs so often, that typically a wide threshold is selected that incorporates 
e entire range of parameter conditions, creating the risk of undetected anomalies. 

Limitations 

ntl Due to cumbersome and time-consuming processes, several limitations exist 
on the current method of analyzing Voyager telecommunications link data. 

oa , , The tedlous manual process for predict generation may take up to two hours 

fpr7^ a ay, K and imit 5 calculat * ons to one P^dict point per hour. Actual link parame- 

n T Lh Y h f r6 T? d 6Very J 1 1 seconds ' leavin 8 quite a disparity between the desired 
number of predictions and the incoming data. 

The ISOE prompts several complications as well. During periods of height- 
ened activity it is possible for a single Telecom event to be embedded among several 
pages of another subsystem’s events in the ISOE. It is easy to miss events, and 
somebmes the ISOE is so extensive that operators do not even attempt to scan it. 

prefer 1 vf/o 6 y ° n an ^ nof:flcial graphical sequence hardcopy product, the Spacc- 
craft Wight Operations Schedule (SFOS), to monitor critical events. The SFOS 
which is manually highlighted with a marker to indicate changes, creates problems 
when users unknowingly do not reference the latest activity modifications. 

,, The c . UI T ent Voyage, ’ata display system presents another area of limitation. 

It allows only five plot display pages for the entire spacecraft team. The Telecom- 
munications subsystem has control of a single page. One display page is capable of 
up to f t] ? ree P otted channels. In order to change the plot parameters to 
select different channels to display, the operator must punch a card and feed it into 
the system s card reader. To obtain an additional plot, special permission must be 
secured from personnel of another subsystem who are willing to temporarily give 
up one of their own plots. v y 6 

Broadened alarm limits present obvious complications. If, in fact, a compo- 
nent is in alarm within the broadened range, this condition will go undetected. If 
spacecraft activities warrant an alarm limit change, and if the operator chooses to 

forego the unwieldy paperwork process, then he must endure the false alarm for the 
remainder of that spacecraft activity. 
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A tabular display of spacecraft parameters is available which indicates alarms 
by reversing the color of the alarmed channel's field. However, this display is sel- 
dom used, as the operator is usually viewing plotted data on the one allotted Tele- 
com display page. As a result, a Telecom alarm condition generally is not detected 
by the Telecom operator until the Voyager Systems Analyst (who monitors and 
coordinates all subsystems) calls it to his attention. 


Diagnosis 

When a spacecraft or DSS parameter goes into alarm, the cause must be 
determined. In many cases, the condition is actually a false alarm due to inaccura- 
cies precipitated by the limitations of the system. In other instances, the alarm exists 
because of common problems that occur on a frequent basis. For actual spacecraft 
problems, such as the failed radio receiver, hundreds of people must be notified and 
put on alert to solve the emergency. Regardless of the cause or severity of an alarm, 
a standard set of rules is routinely followed to determine the basis of the problem. 
Unfortunately, knowledge of these rules resides with a select few, and the first rule 
of the standard procedure is to consult the expert, even when the situation arises 
from a known false alarm. 


THE SHARP SOLUTION 


SHARP introduces automation technologies to the spacecraft monitoring 
process to eliminate much of the mundane processing and tedious analysis. The 
SHARP system features on-line data acquisition of all required information for 
monitoring the spacecraft and diagnosing anomalies. The data is centralized into 
one workstation, which serves as a single access point for the aforementioned data 
as well as for the diagnostic heuristics. Figure 1 illustrates a top-level view of the 
SHARP system. Shown are the individual modules that comprise the system, as 
well as relevant components that are external to SHARP. 

SHARP is implemented in CommonLISP on a SYMBOLICS 3650 color LISP 
machine. Many components of the system utilize STAR*TOOL {1] (patent pending), 
a language and environment developed at JPL which provides a toolbox of state-of- 
the-art techniques commonly required for building AI systems. The SHARP system 
currently consists of approximately 40,000 lines of CommonLISP code, and 
STAR*TOOL comprises an additional estimated 85,000 lines of CommonLISP code. 









Conventional Automation 

The SHARP system captures raw predicts for on-line storage and processing. 
When the predicts are generated for the Voyager Spacecraft Team as hardcopy, the 
information is transferred over an RS-232C serial line to the SHARP system. Pass 
predicts may then be automatically generated at 15-second intervals, the shortest 
possible time interval between the arrival of any two spacecraft data points. Instan- 
taneous predicts, which are pass predicts corrected in real-time for spacecraft point- 
ing loss and DSS system noise temperature, are also automatically calculated at 15- 
second intervals. Spacecraft and DSS residuals, difference measurements between 
the actual values and predicted values, are automatically derived in real-time. 

SHARP also acquires the ISOE for on-line storage and viewing. A generic 
capability to extract subsystem-specific information has been developed; hence 
Telecom-specific events may be stripped from the ISOE and displayed to enable rapid 
identification of significant Telecom activities to be monitored during any particular 
pass. Editing capabilities facilitate on-line additions, deletions, and other changes to 
the ISOE, thus reducing the likelihood of referencing outdated material. 

New plotting capabilities for the channelized data have also been imple- 
mented withir the SHARP system. The operator can construct as many data plots 
per page, or screen, as desired, although five plots per page seems to be the optimal 
number for effective viewing. The user also possesses the capability to construct 
multiple pages that can be set as a program parameter. The user can change the dis- 
play of plots on any given page at any time with simple menu-driven commands. 

Alarm tables have also been constructed as part of the conventional automa- 
tion process, and placed on-line within the SHARP system. A table for each rele- 
vant spacecraft configuration exists, resulting in alarm limits representative of the 
true thresholds for each data channel. SHARP determines alarm limits dynamically 
in real-time and accurately reflects each spacecraft or DSS configuration change. 
Dynamic alarm limit determination eliminates the cumbersome alarm change 
paperwork process as well as many occurrences of false alarms. 

Several graphical displays in SHARP automatically highlight alarmed events 
as they occur. These displays offer information ranging from the location of a prob- 
lem to the probable cause of the alarm. 


Enhanced Graphical Capabilities 


The SHARP system provides numerous sophisticated graphical displays for 
spacecraft and station monitoring. A comprehensive user interface has been devel- 
oped to facilitate rapid, easy access to all pertinent data and analysis. Displays have 
been constructed which range from the placement of data on-line to the creation of 
detailed graphics that provide a multitude of information at one glance. An inter- 
face exists for each major module of the SHARP system. Each interface provides 
customized functions that allow data specific to that module to be easily accessed, 
viewed, and manipulated. Each SHARP module can be accessed from any other 
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module at any time, and all displays are in color with mouse sensitivity and menu- 
driven commands. Figure 2 shows the SHARP top-level system status view. 

The Predicts interface in SHARP allows tabular display of raw predicts, pass 
predicts, instantaneous predicts, and residuals for any specified time range. A color- 
coded DSS availability graph has also been designed which enables rapid identifica- 
tion of available stations for any given viewing period. Situations that mandate 
that another Deep Space Station be acquired can be addressed immediately as 
opposed to the more arduous current method, which requires the manual look-up 
of each station at the specified time period. 

The SHARP system provides an ISOE interface which offers numerous capa- 
bilities to the operator. On-line viewing of any ISOE is available, and intricate mod- 
ifications may be performed with ease. Editing the ISOE is accomplished via menu- 
driven commands that contain explanations of the complex ISOE data. For exam- 
ple, CC3A32330 means that the x-band modulation index is 32, the two drivers are 
on, the subcarrier frequency is high, and the data line rate is high. Translation of 
these spacecraft commands from their raw form into more understandable sum 
maries of spacecraft activity may be performed, and the user can request status sum- 
maries of any activity. A history display is maintained as the ISOE is updated so that 
the user can verify modifications. 

SHARP'S display that plots the channelized data, illustrated in Figure 3, is a 
significant improvement over existing capabilities. The user dynamically cus- 
tomizes the display at any time by selecting which and how many channels to view, 
the time scale, the data range for each plot, and even the icon to use for graphing 
points on each channel. Each plot is color-coded by the user for easy visual distinc- 
tion between displayed channels. When any channel is in alarm, its corresponding 
data points are plotted in red, facilitating rapid detection of an alarm condition. The 
channel's associated alarm limits may be optionally overlaid onto the channel's plot 
for further information. Each data point is mouse-sensitive to provide tinv' and 
numerical value indicators, and an automatic counter continually indicates the 
number of data points per plot. Pan and zoom features augment this display, which 
ca >. represent information as graphs of actual or derived data vs. time, xy plots, scat- 
ter plots, or logarithmic scales. 

The SHARP system also provides an alarm limit interface which allows on- 
line viewing and editing of established spacecraft engineering alarm limits, DSS 
performance limits, ground data system limits, and residual thresholds. Authorized 
users may permanently alter any of these limits, and specified values may be 
changed temporarily for the remainder of that particular spacecraft pass. The latter 
capability, manual override, enables alarm suppression or closer scrutiny for any 
particular event, with no intervening paperwork. 
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Plotting Capabilities Available in SHARP 
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Among the new graphical analysis capabilities provided by the SHARP sys- 
tem is the Telecom link status display, as shown in Figure 4. Actual station cover- 
age is illustrated, along with spacecraft transmitter power status, data rate, data out- 
ages, and real-time recording of station uplink (signal transmission) and projected 
downlink a round-trip light time later. Detailed analysis is performed and informa- 
tion is subsequently color-coded to represent changes in status. The display provides 
the user with such valuable information as time ranges and explanations of data 
outages (e.g., no station coverage or ongoing spacecraft maneuver), and can warn 
the operator when to expect noisy data and why. 

SHARP system also features on-line functional block diagram schematics 
ot the end-to-end communications path from the spacecraft through the Deep Space 
Communications Complex and Ground Communications Facility (GCF) to the Mis- 
sion Control and Computing Center (MCCC) at JPL and final destination of the Test 
and Telemetry System (TTS) computers. Each top-level system status may be 
viewed at successive levels of detail. The Telecom subsystem is very comprehen- 
sive, as spacecraft schematics have been developed for the all of its individual com- 
ponents. These dynamic block diagrams are driven by various ISOE status indica- 
tors and the channelized data. The status of spacecraft and DSS components (opera- 
tional, off-line, or in alarm) is depicted by color, facilitating rapid status identifica- 
tion at a glance. Figure 5 shows the Telecommunications subsystem and Figure 6 
illustrates the spacecraft receiver with associated diagnostic messages. 


, . . ^^™, 8r f phical dis P la y that combines various sources of information and 
data is SHARPS Attitude and Articulation Control display. This display combines 
spacecraft motion parameters (pitch, yaw, and roll) and projects spacecraft move- 
ment over time. A limit cycle box which represents defined spacecraft deadband 
limits encloses the spacecraft icon. Alarm conditions are easily detected as the 
spacecraft icon drifts outside of the designated deadband box. Trailing vectors estab- 
lish the path of the spacecraft. 

The SHARP system also contains special processing modules to perform 
subsystem-specific analysis. For the Telecommunications subsystem, a Fast Fourier 
ransform (FFT) of the DSS conical scanning component is performed to indicate 
when the antenna is going off point. This is a relatively common event, which cur- 
rently may take hours to detect and correct. Spacecraft and scientific information 
can be permanently lost when this situation occurs. SHARP'S FFT display illustrates 
the results of a FFT process performed on 64 data points of a particular channel, and 
provides instant information on conical scan error. The problem can be detected in 
a matter of minutes, and the station can be contacted to correct the antenna move- 
ment prior to the loss of data. 
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Figure 4. SHARP Telecommunications Link Status Display 
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Figure SHARP Schematic Block Diagram of Voyager Telecommunications Subsystem 





Figure 6. SHARP Schematic Block Diagram of Spacecraft Receiver With Message From Diagnostician 







1 ■j' "• ■ ■■ ■ r --* 1 «-■■*> 'vs- w ■■- >«• w-sf-rj»»rt* r^nasssT jf*w *■ tt*/^-'**** f -v ^ ■ 


Artificial Intelligence 

The AI modules of SHARP are written in an expert system building language 
called STAR*TOOL. STARTOOL is a programming language designed at JPL to 
meet many of NASA s demanding and rigorous AI goals for current and future 
projects. The appendix contains a more detailed description of the STAR’TOOL 
system. 

AI techniques are distributed throughout all components of the SHARP sys- 
tem. Intelligent programming methodologies such as heuristic adaptive parsing, 
truth maintenance, and expert system technology enable more effective automation 
and thorough analysis for SHARP functions. Fault detection becomes almost 
immediate with a greater degree of accuracy and precision, and the system quickly 
generates fault hypotheses. The structure of SHARP'S AI module is illustrated in 
Figure 7. 

A blackboard architecture, provided by STAR*TOOL, serves as a uniform 
framework for communication within the heterogeneous multi-process environ- 
ment in which SHARP operates. Generally, when two or more processes are coop- 
erating, they must interact in a manner more complicated than simply setting global 
variables and passing information along such paths. SHARP provides a standard- 
ized method of communication between multiple processes, which include real- 
time posting of incoming telemetry data and the monitoring of data networks. 

Heuristic adaptive parsing is implemented for SHARP'S raw predicts data- 
base. Periodically the format of this data source changes without mission operations 
being notified. Generally this would require the raw predicts parser to be rewritten 
to incorporate the new format. However, SHARP utilizes Augmented Transition 
Network (ATN) [2] techniques to accomplish adaptive parsing. The advantage of 
such an ATN lies in its ability to parse the database according to semantic content 
rather than syntactic structure. The raw predicts database can therefore be modified 
and yet remain successfully parsable. This heuristically controlled, format- 
insensitive parsing ensures continuity despite format modifications in predict gen- 
eration. 


The centralized database of the SHARP system serves as a central repository of 
all real-time and non-real-time data, and functions as a local buffer to enable rapid 
data access for real-time processing. Numerous database manipulation functions 
have been implemented, and database daemons have been constructed to imple- 
ment spontaneous computations [3]. Requests can be made to the database to trigger 
arbitrary activities when a complex combination of past, present, and future events 
occur. A wide selection of retrieval methods by time or value highlight the flexibil- 
ity inherent in the database. Requests to the database can be made from both AI and 
non-AI modules of SHARP, and can be handled serially or in parallel. 
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Various SHARP modules represent and manipulate data symbolically rather 
than numerically so that particular numeric values can change without forcing the 
algorithms themselves to be modified. For example, to determine if a channel is in 
alarm, the rule interpreter manipulates one symbolic fact, ChannellnAlarm, rather 
than the many numeric operations that are required to make an actual determina- 
tion. This is a significant advantage as SHARP presently analyzes over 100 chan- 
nels, and the alarm determination process varies from channel to channel. Sym- 
bolic representation and manipulation of data also simplifies the exchange of infor- 
mation between SHARP modules and reduces reliance on specific dimensionless 
numeric values. 

The diagnostic component of SHARP is composed of a hierarchical executive 
diagnostician coupled with cooperating and non-cooperating mini-experts. Each 
mini-expert is responsible for the local diagn s of a specific fault or class of faults, 
such as particular channels in alarm, conical scan errors, or loss of telemetry. A 
non-cooperating expert focuses only on its designated fault area, but a cooperating 
expert has the additional capability of searching beyond its local area to identify 
related faults that are likely to occur. Cooperating experts are used in situations 
where the identification of a particular fault cannot be made by examining a single 
fault class alone. 

The executive diagnostician combines input propagated from each local diag- 
i nostician and reviews the overall situation to propose one or more fault hypotheses 

I and recommended corrective actions. When multiple fault hypotheses are gener- 

I ated, the system lists all possible causes of the anomaly and ranks each according to 

* plausibility. 

I 

f If one or more of the cooperating experts fails, the executive diagnostician 

| vvi11 continue to operate with only a reduction in the area of local diagnosis that 

| would have been derived from the failed mini-experts. Similarly, if the executive 

| diagnostician fails, the cooperating experts will locally diagnose the faults in isola- 

j tion of multiple fault consideration. 

The diagnostician is implemented in rules that execute in pseudo-parallel in 
pursuit of multiple hypotheses. Pseudo-parallelism is implemented in SHARP 
using facilities provided by STARH’OOL, which includes parallelism as a funda- 
mental control structure. The diagnostic rules operate in isolation of one another by 
executing in independent contexts [4] provided by the STAR*TOOL memory model, 
and communicate through the Blackboard facility. 

! These contexts can be organized into a tree-like structure to represent contra- 

dictory information resulting from changes in facts or from the introduction of new 
or contradictory hypotheses. Facilities in the truth maintenance system 151 handle 
data- and demand-driven diagnoses to ensure an appropriate balance between the 
persistence of hypotheses and sensitivity to new data. 

Bayesian inference processes are used for comparing multiple hypotheses and 
for prioritizing conflicting fault hypotheses. Bayesian inference procedures also 


I 
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perform uncertainty management to allow continued high performance in the 
presence of noisy, faulted, or missing data. F ormance in me 

maintenan ce system constantly monitors for violations of loeical 
consistency For example, it performs conflict checking to maintain consistency 
among multiple rule firings, hypotheses, and the knowledge base, and allows the 
context-sensitive management of alarms through a complex response system to 
combinations of alarm conditions. Truth maintenance techniques also provide a 
variety of functions for temporal reasoning in multiple fault diagnosis. ? 

CONCLUSIONS 

mp n f a ? d ground data s y ste ^s operations present a rigorous environ- 

ment in the area of monitoring and anomaly detection and diagnosis. With a 

number of planetary missions scheduled for the near future the effort to staff and 
support these operations will present significant challenges 

The SHARP system is an attempt to address the challenges of a multi-mission 
monitoring and troubleshooting environment by augmenting conventional Tuto 

toda°te hatl n are 8 aTvb lth 8 ^^ f - the ? rt artificial intelligence 8 Results of this effort 
mpf-hnrirJ ea ^k e gun to show significant improvements over current Voyager 

Voyagt operLL n ns. haVe dem0nstrated P otential enhancements to several aspects of 

cons i d pra h 1 p^hpn ®/ a u t 5 >ma don technology will endow mission operations with 

canhirpH ^H b f t ln f S man ?I *1*™ aS are automat ed, expert knowledge will be 
dnmpin^ d P er ™ anentI y recorded, reducing the frenzied state that occurs when 

r"TSf a T U T their in ]P end ing retirement. Cost reductions will 
occur as a result of automation and decreased requirement for 24-hour real-time 

af 8oT r Arnnm 8 f : f m n V A he P ° SSible t0 reduce the reaI - time workforce by as much 
80%. Automatic fault detection and analysis will facilitate quicker response times 

cHARp? n v an0ma K h f! and more accurate conclusions. The time savings Afforded by 
lke ^P 3 *’ 111 * 1 ® 8 ' especially during periods of unmanned operation or dur- X 
g emergencies, could mean the difference between the loss or retention of critical 
data, or possibly even of the spacecraft itself. or cntlcal 
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APPENDIX 


STAR*TOOL 

Knowledge-based systems for automated task planning, monitoring, diagno- 
sis, and other applications require a variety of software modules based on artificial 
intelligence concepts and advanced programming techniques. The design and 
implementation of such modules requires considerable programming talent and 
time, and a background in theoretical artificial intelligence. Sophisticated software 
development tools that can speed the research and development of new artificial 
intelligence applications are therefore highly desirable. The STARTOOL system 
was developed specifically for this purpose. STAR*TOOL is currently available for 
license to industry and academia from the California Institute of Technology, Office 
of Patents and Technology Utilization. Included in the system are facilities for 
developing reasoning processes, memory-data structures and knowledge bases, 
blackboard systems, and spontaneous computation daemons. 

Computational efficiency and high performance are especially critical in arti- 
ficial intelligence software. This consideration has been an important objective of 
STAR*TOOL, and has led to its design as a toolbox of AI facilities that may be used 
independently or collectively in the development of knowledge-based systems. 

STARTOOL provides a variety of facilities for the development of software 
modules in knowledge-based reasoning engines. The STARTOOL system may be 
used to develop artificial intelligence applications as well as specialized tools for 
research efforts. 

STARTOOL facilities are invoked directly by the programmer in the 
CommonLISP language. For improved efficiency, an optional optimization com- 
piler was developed to generate highly optimized CommonLISP code. 

STARTOOL was designed to be efficient enough to operate in a real-time 
environment and to be utilized by non-LISP applications written in conventional 
programming languages such as ADA, C, Fortran, and Pascal. These non-LISP 
applications can run in a distributed computing environment on remote comput- 
ers, or on a computer that supports multiple programming languages. 
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